The present invention relates to the management of security key distribution, most typically within a community of anonymous users all of whom are sharing a secure service, which may be the provision of content or the provision of a resource for example.
One example of such a situation is one in which a large number of anonymous users subscribe to a service providing shared content which is updated on a regular basis. To protect the interests of the provider of the content such content is usually distributed to bona fide users (also known herein as “subscribers”) in an encrypted form. This prevents non-subscribers from gaining access to the content and thereby diminishing its financial value to existing subscribers, and thus ultimately the pecuniary advantage that may be obtained by the provider. In one example each subscriber is given a key which they may use to decrypt content; to protect the interests of subscribers, such a key should ideally neither identify them nor enable such identification. However, it has long been established that managing the provision and maintenance of security keys to a large group of anonymous subscribers is difficult. For example, one way in which both the anonymity of the subscribers may be preserved and the provision of keys may be made simple is to give each user the same security key, however this has negative implications on the security offered by such a single key. In an alternative key management method, each user is issued with a key which is unique, at least within the provider of the content, but which does not identify the subscriber, and which functions to decrypt only content sent to that subscriber. In such a scenario, upon lapsing of the subscription, it is possible to invalidate this unique key by ceasing to make content available in a form which is decryptable using the key issued to the now-lapsed subscriber. However owing to the manner in which such keys are generated in the vast majority of instances, the revocation of even such unique keys from lapsed subscribers requires a reconfiguration of all other subscriber's keys, at least to some extent, and eventually, when sufficient keys have been invalidated, the need to reissue keys in their entirety to all subscribers.